Why add it without any in-tree users?

Why add it without any in-tree users?

Hi @henrikbrixandersen , most because now any devicetree vendor prefix will be checked. This vendor prefix is mandatory to even introduce the SoC vendor, draft #37686 to check CI complains. This may help community to select same prefix too, since some people prefer to work with stable versions. On my view, it is doable have it on LTS to help with backport code that will be introduced after LTS release. I understand if need wait.

This vendor prefix is mandatory to even introduce the SoC vendor, draft #37686 to check CI complains.

Then this change should be done in the PR introducing support for that vendor, not here

This vendor prefix is mandatory to even introduce the SoC vendor, draft #37686 to check CI complains.

Then this change should be done in the PR introducing support for that vendor, not here

Hi all,

I think this is something that any Zephyr members should waist time. There is a draft at #37686 ( mentioned ) which already shows the intention to have this SoC in tree. There were added two pre requirements at RISC-V to allow introduce the SoC (already accepted inclusive). If vendor prefix goes couple weeks before or at same time is complete irrelevant because it will be there anyway. It will be backported to LTS soon or later and this change not hurts LTS 2.7.1 or any release. However, having this sooner helps on development.

This is type of fight that is a complete waist of time and if this is really important, Zephyr should remove all manufacturers from vendor list that are not in tree instead simple copy list from Linux.

@henrikbrixandersen , I agree with you in the case of a random vendor, without any intention to add at least a board, but it is not the case.

However, having this sooner helps on development.

How does it help development to have this in sooner?

This is the argument: Why add it without any in-tree users?
Is this documented? If not, we shouldn't waist more time.

Is this documented? If not, we shouldn't waist more time.

The waste of time is adding a vendor prefix for some vendor that we have no upstream bindings for.

It seems like there is some frustration here, so I'm going to suggest going with the route that makes everyone happy (@nandojve gets his changes in, @henrikbrixandersen and @mbolivar-nordic do not see DT prefixes without in-tree users).

@nandojve - can you please cherry-pick this commit into another of your PRs that also includes an in-tree user and close this PR?

Sorry for any mixed-signals.

@mbolivar-nordic - I wonder if there needs to be some kind of officially documented process for adding an SoC / HAL. It's tricky and there are a lot of nuances particularly with adding a new HAL.

Alternatively, I wonder if it's really just an artificial technical limitation. In particular, for modules, I wonder if it's possible for the module extend upstream Zephyr DT prefixes. My guess is that @nandojve needs this for CI in a downstream fork or module and it would just make that easier if it was already upstream, but what if we eliminated that as a source of contention?

In particular, for modules, I wonder if it's possible for the module extend upstream Zephyr DT prefixes. My guess is that @nandojve needs this for CI in a downstream fork or module and it would just make that easier if it was already upstream, but what if we eliminated that as a source of contention?

Out-of-tree lists of vendor prefixes for use in CI is already supported. Please see #39019 (comment). We use many dts bindings in our downstream with vendor prefixes not present in upstream Zephyr.

@mbolivar-nordic - I wonder if there needs to be some kind of officially documented process for adding an SoC / HAL. It's tricky and there are a lot of nuances particularly with adding a new HAL.

You mean a SoC porting guide in addition to the arch and board porting guides we already have?

https://docs.zephyrproject.org/latest/guides/porting/index.html#

That seems reasonable abstractly, but would probably be hard to write and go stale quickly. I've done a SoC port and I agree it's tricky, but I feel like there are no real rules here, and the sort of people who make changes affecting SoC ports tends to overlap a lot with the sort of people who don't update documentation, in my experience :).

I sent a PR creating a new section with rules for upstream bindings: #39063

Hopefully this will resolve any questions once @galak has returned and has time to review and approve.

Hi all,

Thanks for care with this subject.

@nandojve - can you please cherry-pick this commit into another of your PRs that also includes an in-tree user and close this PR?

Yes @cfriedt , I'll send when introduce SoC with minimal serial driver and board.

I sent a PR creating a new section with rules for upstream bindings: #39063

Thank you @mbolivar-nordic for your initiative to document and avoid any future issues related to this. Bring a new SoC is already a complex task and have a lot of nuances and, sometimes can be very frustrating. This helps people to understand better what is expected and avoid issues.

I would suggest that Q/A at #39019 (comment) could be translated to some samples/application_development/out_of_tree_ sample in future. Thanks for point that @henrikbrixandersen.

Thank you for your understanding @nandojve -- I know SoC porting is a pain, but hopefully this part of it at least is resolved for now.